Answers @kumavis's challenge of "What're you afraid of CapTP or
something?" by replacing our kernel JSON-RPC API with `E()` on a facet
of the kernel. This makes it easy to expose as much of the kernel API as
we want via eventual send, and allows us to benefit from pipelining
internally. In addition, it facilitates the removal of the command
stream and the related RPC API logic. Finally, a number of
rationalizations are applied to the extension and omnium.

This PR is part of a stack followed by: #752, #753, and #754



<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Introduces CapTP-based communication and removes the JSON-RPC command
stream.
> 
> - Add CapTP utilities in `kernel-browser-runtime`:
`makeBackgroundCapTP`, `makeKernelCapTP`, `makeKernelFacade`, and
JSON-RPC `captp` notification helpers; export new `KernelFacade` and
`CapTPMessage` types
> - Update `kernel-worker` to use CapTP for background↔kernel messaging;
initialize kernel without a command stream; route internal RPC only for
panel/internal comms
> - Refactor `@MetaMask/ocap-kernel` to drop command stream handling and
kernel RPC entrypoints; `Kernel.make` now accepts only platform services
and the database; adjust `stop()` accordingly
> - Migrate extension and omnium backgrounds/offscreens to CapTP over
`ChromeRuntimeDuplexStream`, use global `E` and `kernel`/`omnium`
helpers; remove `env/dev-console` and background trusted prelude files;
add TS globals
> - Add unit and integration tests for CapTP (`background-captp`,
kernel-side CapTP, and E() end-to-end); introduce
`vitest.integration.config.ts` and `test:integration` scripts; CI gains
an "Integration Tests" job
> - Update deps (add `@endo/captp`, `@endo/eventual-send`), tsconfigs,
build constants, and minor coverage thresholds
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
cbf22fd. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>

Introduces "controllers" to Omnium. A controller is an object (class)
responsible for a slice of application state. We inherit this
nomenclature from MetaMask.

In detail:
- Add modular controller architecture with POLA attenuation via
`makeFacet()`
- `makeFacet()` is tentative, and may be removed later in the stack in
favor of just public and private methods.
- Add `ControllerStorage` abstraction with `immer`-based state
management and debounced persistence
- Add platform storage adapters and Chrome-specific implementation
- Add `Controller` abstract base class
- Add `CapletController` for managing installed caplets

**Part 2 of 4 in PR stack**
Depends on: #751
Followed by: #753 



<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Introduces a modular controller layer and integrates it into the
extension background, enabling managed, persisted state and caplet
lifecycle operations.
> 
> - **Controller framework:** Adds abstract `Controller`,
`ControllerStorage` (immer-based with debounced, per-key persistence),
and a Chrome storage adapter
> - **Caplet management:** New `CapletController` with
`install/uninstall/list/get`, manifest validation, and kernel subcluster
launch/terminate via `initializeControllers`
> - **Background integration:** Refactors globals to `omnium` (`E`,
`getKernel`, `ping`) and exposes `omnium.caplet` methods; adds error
propagation to offscreen stream
> - **Types/utilities:** Exports `Promisified` type; caplet types/guards
with superstruct and semver
> - **Config/tests:** Adds deps (exo, superstruct, immer, semver),
grants `storage` permission in manifest, and comprehensive unit/e2e
tests
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
0e330b6. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>